home *** CD-ROM | disk | FTP | other *** search
/ Amiga Tools 3 / Amiga Tools 3.iso / grafik / raytracing / rayshade-4.0.6.3 / inetray / faq < prev    next >
Text File  |  1993-08-17  |  4KB  |  74 lines
  1. ======================================================================
  2.                     F A Q 
  3.                     doc: Fri Apr 24 14:58:47 1992
  4.                     dlm: Tue Aug 17 16:52:34 1993
  5.                     (c) 1992 ant@ips.id.ethz.ch
  6.                     uE-Info: 10 57 T 0 0 72 3 2 8 ofnI
  7. ======================================================================
  8.  
  9. Q: I get the message ``Warning: stderr is lost!'' in the messages file.
  10. A: Recompile everything with the NOASYNCIO_QUIRK defined.
  11.  
  12. Q: When I issue an inetray or an inetray.ping I get a a dot every few
  13.    seconds and the program does not seem to proceed.
  14. A: There is either another process using the same socket running on your
  15.    machine (another inetray, maybe), or the servers didn't terminate
  16.    normally on your last session. You can check by issuing netstat -f
  17.    inet.
  18.    If there are still workers running on remote machines, you just have
  19.    to wait roughly one minute to give them time to shut down orderly; if
  20.    another program uses the same port, you have to add a resultport:
  21.    definition to your ~/.inetrayrc.
  22.    Note that inetray and inetray.ping will just continue trying on the
  23.    port, printing a dot every few seconds until the problem disappears
  24.    (which eventually will).
  25.  
  26. Q: Why does inetray need so much more memory than rayshade?
  27. A: There are several reasons for this:
  28.    a) The dispatcher needs a lot of memory since it has to buffer a
  29.       whole frame. Rayshade does not have to buffer a whole frame since
  30.       it renders strictly sequentially.
  31.    b) The dispatcher furthermore reads the input file and builds up the
  32.       geometry data. This feature allows printing of the error and
  33.       warning messages before the rendering actually starts (and cloggs
  34.       the syslogs on the worker machines). The memory could and should
  35.       be freed after checking the input before allocating the frame
  36.       buffer but this is not done at the moment.
  37.    c) On every worker machine the inputfile is read and geometry built
  38.       up for every used CPU - if you use more than one CPU you need more
  39.       memory. This simplifies the handling of multiple CPUs greatly:
  40.       every CPU can be viewed as simply another machine. No special code
  41.       is required.
  42.    d) The actual work is handled by a forked process. This process is a
  43.       copy of the server process and contains all geometry data.
  44.       Therefore, 2 copies of all data exist for each CPU used. This
  45.       solution is quite ugly in terms of memory but very nice in terms
  46.       of simplicity. Without forking a new process, process controls
  47.       (basically sending remote signals) would be very hard if at all
  48.       possible without changing the rayshade source. The parent must
  49.       keep the memory because it will fork further workers later on.
  50.  
  51. Q: I don't seem to be able to ignore a host from my ~/.inetrayrc file.
  52. A: add ignore: name, where name is the exact(!) string as printed by
  53.    inetray.ping.
  54.  
  55. Q: I had problems in the last session and now there seem to still be
  56.    servers/workers running and/or connections open.
  57. A: Issue an inetray.kill in the same directory where you started the
  58.    problem session. All what's left running after that should kill
  59.    itself after roughly a minute anyway.
  60.  
  61. Q: I think Inetray is a great program and I want to send loads'a money
  62.    to the author to thank him.
  63. A: Do so: Andreas Thurnherr, Birkenstr 3, 8640 Rapperswil, Switzerland.
  64.    
  65. Q: When I trace, workers register correctly but suddenly I get a lot of
  66.    messages about lost connections.
  67. A: The workers terminated while reading and processing the input-files.
  68.    Check for error messages in your syslog (or in your temp-directory if
  69.    NOASYNCIO_QUIRK is set). Usually the files are not there or not
  70.    accessible for the user under which the servers are running. Note
  71.    that files like /tmp are usually there on every machine but they are
  72.    different even on machines which share there filesystems.
  73.    
  74.